Skip to content

Conversation

@barraguda
Copy link
Contributor

@barraguda barraguda commented Dec 9, 2024

Problem

Versions of kns_indexer that keep hashmaps of names in memory (and or serialize that entire state and save it) will at some point run into memory limits and or just performance issues when indexing many events.

Same goes for app_store.

Solution

This PR uses key value as a hashmap on disk for KNS, doing gets and sets directly to disk.

For app_store, it uses the sqlite runtime module for better querying capabilities in the future too,

Notes

Some things that will still be added:

  • iterator support for KvAction (needed for state printouts now that we don't keep all keys in memory)
    • this is also needed for the consequent update of app_store (serves GetApps request often)
  • reset logic (now involving a full delete of the package db in /kv inside the home folder)

@dr-frmr
Copy link
Contributor

dr-frmr commented Dec 9, 2024

Does this fully replace #614 ?

@barraguda
Copy link
Contributor Author

Does this fully replace #614 ?

yes, app_store work pending

reviews from that one have been assessed here though

@barraguda barraguda changed the title kns: new serialization strategy kns & app_store: new serialization strategy Dec 10, 2024
Comment on lines 101 to 107
println!(
"kns_indexer: loaded state: version: {}, last_block: {}, chain_id: {}, kimap_address: {}",
state.version,
state.last_block,
state.get_chain_id(),
state.get_contract_address()
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this is going to print on every boot it should be aesthetically pleasing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like this maybe?

Tue 17:09 kns-indexer:sys:
     🐦‍⬛  KNS Indexer State
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Version         1
Last Block 129424597
Chain ID       10
KIMAP      0xcA92476B2483aBD5D82AEBF0b56701Bb2e9be658
▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line up the number values horizontally but yes :)

// includes keys and values for:
// "meta:chain_id", "meta:version", "meta:last_block", "meta:contract_address",
// "names:{namehash}" -> "{name}", "nodes:{name}" -> "{node_info}"
kv: Kv<String, Vec<u8>>, // todo: maybe serialize directly into known enum of possible types?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you resolve this TODO before merge? what is the type going in here? it looks like just nodes, and then a handful of static types

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, the KV struct currently takes in a type for the value, I'll see if I can relax that requirement in the process_lib with a specific function passing in <K,V> rather than at instantiation.

non-static-types right now: Strings for names and namehashes, net::KnsUpdates for node_infos

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using set_as:: and get_as:: reduced code amount here some, but left the default as Vec instead of having some bigger enum to match and serialize.

hyperware-ai/process_lib#123

@barraguda barraguda changed the base branch from develop to v0.10.0 December 17, 2024 12:54
Copy link
Member

@nick1udwig nick1udwig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small question otherwise LGTM

state
}

fn meta_version_key() -> &'static str {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it best practice to return a static str and then .to_string() it, as we do below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably not, kv helper takes ownership to serialize, so made those helpers just return a String directly instead!

.send()?;
}

IndexerRequest::NodeInfo(NodeInfoRequest { ref name, .. }) => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: should we add a kimap.get() call here (if we happened to miss an event), or have a separate IndexerRequest for it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes we should. lazy eval/correctness in indexer. also in net runtime module need to do same thing.

@barraguda barraguda merged commit 6dfb341 into v0.10.0 Dec 17, 2024
1 check passed
@barraguda barraguda deleted the bp/kvstate branch December 17, 2024 22:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants